1. Field of the Invention
The present invention relates generally to a sleep controller in a mobile communication system, and in particular, to an apparatus and method for controlling a slotted mode of several systems using one sleep controller in a hybrid terminal.
2. Description of the Related Art
Hybrid terminals capable of accessing and communicating with several types of communication networks, such as Code Division Multiple Access (CDMA), Global System for Mobile communication/General Packet Radio Service (GSM/GPRS), Universal Mobile Telecommunications System (UMTS), etc. are classified into three groups. The first group is limited to a terminal that can simultaneously access several communication networks, enabling inter-system handover; the second group consists of a terminal that can access one communication network at a time; and the third group is limited to a terminal having a mixed function of the other two terminals. The first group can be further classified into a terminal that includes Radio Frequency unit (RF) and Modem Hardware (H/W) separately for each individual system, and a terminal that includes the hardware simultaneously shared by several systems.
Most wireless communication protocols adopt a slotted mode to reduce power consumption. In the slotted mode, each terminal, after acquiring its initial synchronization, is allowed to monitor only the slot allocated thereto for the most time because a base station separately transmits specific messages to each individual terminal, like the page message, only at the slot allocated to each individual terminal.
A detailed description thereof will now be made with reference to the accompanying drawings.
FIG. 1 shows the timing of the slotted mode operation of a terminal in a general mobile communication system.
In FIG. 1, a particular terminal (or mobile station) determines receipt/non-receipt of a call or a message at a paging channel slot #5 allocated thereto.
For the other time, the terminal operates in power save mode that turns off power of all blocks except for the minimum hardware required for maintaining time synch, in order to reduce power consumption of the terminal. Generally, an interval for which the terminal operates in the power save mode is referred to as a sleep interval, and an interval for which the terminal normally operates is referred to as an idle interval, or a wake-up interval. In the sleep interval, the terminal counts a slow clock and the time that a sleep controller should wake up.
Sleep and wake-up processes of the terminal operating in the slotted mode are as follows.
A protocol stack of each system checks a sleep condition, and at a possible sleep time, the protocol stack calculates an expected sleep time, provides the sleep time information to a sleep controller, and turns off appropriate hardware blocks in sequence.
The sleep controller turns off the main clock of the modem at the next Pseudo Noise (PN) boundary, and counts the slow clock to generate a wake-up interrupt at the time that the terminal should wake up. The protocol stack provides information on timing offset between the main clock and slow clock to the sleep controller, and the sleep controller turns on the main clock of the modem at the correct time after compensating for the timing offset. The protocol stack turns on the appropriate (powered-off) hardware blocks. After waking up, the terminal performs a series of necessary operations after re-acquiring time synch with the base station, and repeats the sleep/wake-up processes in the same manner.
In the hybrid terminal having the hardware simultaneously shared by several systems, the sleep/wake-up controller is more complex. This is because the possibility of an operation of each system is determined according to priority determined separately for each individual system. For example, even on the condition that one system can sleep, whether the terminal can sleep is determined according to situations of other systems, and even on the condition that one system can wake up, whether the terminal can wake up is determined according to situations of other systems.
FIG. 2 is a diagram of a structure of the conventional hybrid terminal.
In the conventional hybrid terminal, as shown in FIG. 2, systems 205 and 210 each independently perform sleep control using their own sleep controllers 220 and 230, and systems 205 and 210 each independently control shared hardware resources 225, such as RF and modem. To prevent collision between systems, the hybrid terminal uses a system arbitrator 215, which is a control module for analyzing situations of all systems and determining whether to operate a particular system according to the analysis result. Each system sends a request for sleep or wake-up to system arbitrator 215 when necessary, and determines the next expected operation according to a response from this module.
A detailed description will now be made of an example of sleep/wake-up processes of the hybrid terminal.
In a terminal where two systems 205 and 210 operate, it is assumed that a system-1 protocol stack (PS) 205 performs the wake-up process, and a system-2 PS 210 performs the sleep process.
If system-2 PS 210 sends in Step 1 a sleep request to system arbitrator 215 as it is in a sleep condition, system arbitrator 215 informs in Step 2 system-2 PS 210 whether it will turn off the hardware, depending on the entire system situation. System-2 PS 210 sets a sleep controller #2 230 in Step 3, and turns off the hardware in Step 4 if needed.
Sleep controller #1 220 reports the occurrence of the wake-up interrupt to system-1 PS 205 in Step 5, when a wake-up interrupt has occurred therein, and system-1 PS 205 sends a wake-up request to system arbitrator 215 in Step 6. System arbitrator 215 informs in Step 7 system-1 PS 205 if it can wake up or it should turn on the hardware, depending on the entire system situation. In the situation where it cannot wake up, system-1 PS 205 calculates the next sleep interval and re-sets the sleep controller #1 220 in Step 8. In the situation where it should turn on the hardware, system-1 PS 205 turns on shared hardware 225 in Step 9. In addition to these control paths, there are possible interfaces with which the systems each report system situations, such as state change, to system arbitrator 215.
Even in the situation where one system has entered the sleep mode, when another system waits for an operation, the system should not turn off the shared hardware, such as RF and modem. In this case, if a system intending to sleep sends a sleep request to the system arbitrator, the system arbitrator notifies this situation to the system that has sent the sleep request. Upon receipt of the response from the system arbitrator, the system only operates its sleep controller without turning off the shared hardware, to inform the time that it should wake up.
Even though a wake-up interrupt has occurred in a sleep controller of an arbitrary system, if another system, which has higher priority than the system, is in operation, the system cannot wake up. Upon receipt of the wake-up interrupt from the sleep controller, the system sends a wake-up request to the system arbitrator, and the system arbitrator informs the requesting system of wake-up possibility and hardware-on possibility taking into account the situations of all systems. When wake-up is impossible, the system should sleep again until its next slot, and this is an inevitable process in the system sharing the hardware. Even though wake-up is possible, when the system needs to turn on the turned-off hardware resources, it additionally needs a hardware control process of compensating for a clock offset and turning on the clock and hardware, in addition to the software wake-up process. Otherwise, the system performs only the software wake-up process.
During a catnap when periodical wake-up of the Central Processing Unit (CPU) is performed to recognize an external input such as key interrupt or folder opening, the control gets even more complex. This is because the catnap is needed only when all systems are in the sleep mode, and the system should be able to process external inputs when all systems are in operation after waking up.
The conventional sleep control system operating in this manner needs as many sleep controllers as the number of systems, thus suffering from increased hardware complexity and a reduction in extensibility due to the large number of interfaces. In addition, sleep and wake-up processes should be implemented in all systems, causing an increase in overhead for realizing a protocol stack.
In addition, because the system arbitrator should have information on the current states of all systems, every time its state changes, each system should report the change to the system arbitrator, causing software overhead. Further, even during sleep and wake-up, each system should always send a report to the system arbitrator and receive necessary information there from, causing existence of many control paths and thus an increase in the processing time.